ソフトウェアアーキテクチャの基礎輪読会 15章

日付：2023/11/22

章：スペースベースアーキテクチャ

要約

高いスケーラビリティ、弾力性、同時実行性を目的にしたアーキテクチャ

各処理ユニットのメモリ内にデータを持ちながら、DBの読み書きを非同期ですることで、DBの制約を無視できる。

スペースベースアーキテクチャが解決する課題

一般的なWebアプリケーションのリクエストフロー

ブラウザからの要求 -> Webサーバー -> アプリケーションサーバー -> DBサーバー

図15−1参照

このパターンは少数のユーザーには最適だが、ユーザーの負荷が増えると、Webサーバー層、次にアプリケーションサーバー層、最後にデータベースサーバー層でボトルネックが発生し始める。

負荷対策にはスケールアウト(サーバーの数を増やすこと)が有効。

だが、Webサーバーをスケールアウトするとボトルネックがアプリケーションサーバーに移動する。アプリケーションサーバーをスケールアウトすると、DBサーバーにボトルネックが移動するのように、最終的にはDBサーバーに負荷が移動し根本的解決になっていない。

概要とトポロジー

図15−2参照

アプリの標準的なトランザクションに中央のDBが関与しない

これによりDBのトランザクションというボトルネックが解消され、アプリのスケーラビリティが無限になる。

中央のデータベースとの連携ではなく、各処理ユニットがメモリ内部にデータを持つ

そして、メモリ内部のデータが更新されると、更新情報が非同期的に他の処理ユニットに送られ、結果的に複製される。

トポロジー

処理ユニット

アプリケーションコード、メモリ内部のデータグリッド、データ複製エンジンを含む。

データリーダー, データライター

非同期方式で処理ユニットのデータを受け取り、中央のデータベースにメッセージを送る。

仮想ミドルウェア

処理ユニットの管理・調節に使用される

処理ユニット

図15-9参照

ここには通常、webフレームワークなどのバックエンドのビジネスロジックが含まれており、ある種一つのアプリケーションが完成している。

処理ユニットには、(マイクロサービスのように)小さな単一目的のサービスを含めることができる。

メモリ内部のデータグリッドとデータ複製エンジン

各処理ユニットのデータグリッドが同じ名前付きキャッシュを持つデータグリッドの参照を持っている。

キャッシュに加えられた変更は、データ複製エンジンによって、同じ名前つきキャッシュを持つ全ての処理ユニットに複製される。

仮想ミドルウェア

データの同期やリクエスト処理の様々な側面を制御するアーキテクチャ内部のインフラストラクチャに関する問題を処理する。

以下の4つの要素からなる。

メッセージンググリッド(役割はロードバランサー)

ユーザーからのリクエストを、どの処理ユニットに転送するかを管理する

データグリッド(メモリデータの中央)

最近では、処理ユニット内にのみ実装されている

外部コントローラーを必要とするときや、分散キャッシュを使用する場合、必要

処理グリッド

1つのリクエストに複数の処理ユニットの協調が必須となる場合に、それらの処理の指揮、オーケストレーションを行う。

デプロイメントマネージャー

負荷条件に基づいて処理装置インスタンスの動的な始動とシャットダウンを管理する

スケーラビリティ(弾性)のニーズを達成

データポンプ

データポンプは、データベース内のデータを更新する別のプロセッサにデータを送受信する方法。

データポンプはデータ抽出層(あるいはデータアクセス層)を形成する。

この2つの違いは、データベース内のテーブルの構造（またはスキーマ）に関して、処理ユニットがどれだけ詳細な知識を持っているかという点にある

データアクセス層とは処理ユニットがデータベースの基礎となるデータ構造に結合されており、データリーダーとライターを用いてアクセスするだけのものである。

一方のデータ抽出層とは処理ユニットが個別のコンストラクトによってデータベースの基礎となるテーブル構造から切り離されていることを意味する。一般的にスペースベースアーキテクチャではデータ抽出層を採用する。

データ抽出層はDBとデータを切り離せるため、スペースベースアーキテクチャに向いている

データライター

データライターコンポーネントは、データポンプからのメッセージを受け取り、データポンプのメッセージに含まれる情報でデータベースを更新する。(図15−8参照)

また、データポンプ一つに対してデータライターが1つつくこともある。(図15−9参照)

メリット

処理ユニット、データポンプ、データライターの整合が取れることで、より優れたスケーラビリティやアジリティ

デメリット

データライターが多くなりすぎる。

データリーダー

データリーダーはデータベースからデータを読み取り、リバースデータポンプを介して処理ユニットに送信する責任を負う。(図15−10参照)

データリーターは以下のいずれかの状況(一般に避けられているが)で呼びだされる。

同じ名前のキャッシュを持つ、すべての処理装置インスタンスのクラッシュ

同じ名前のキャッシュを持つ、すべての処理装置の再起動

レプリケーションキャッシュに含まれないアーカイブデータの取得

データ衝突

変更があったときにデータを複製するので、複製中のデータ衝突による不整合は起きうるが、確率を計算できる。

衝突率 = N * (UR)^2 / S * RL

Nは同じ名前付きキャッシュを使用しているサービスインスタンスの数、URはミリ秒単位の更新レート（二乗）、Sはキャッシュサイズ（行数）、RLはキャッシュソフトウェアのレプリケーションレイテンシー

https://scrapbox.io/files/655d3a72690aba001c27f212.png

* URをミリ秒単位に変換する必要あり

* 計算式の結果から得られる衝突率の単位は件/ミリ秒

クラウドとオンプレミス

トランザクション処理は動的で弾力性のあるクラウド環境で行い、物理的なデータ管理、レポーティング、データ分析を安全で局所的なオンプレミス環境で行うのようないいとこ取りも可能

図15−11参照

レプリケーションキャッシュと分散キャッシュ

処理ユニットにレプリケーションキャッシュを持たず、外側にキャッシュサーバーを持つ分散キャッシュという方法もある(キャッシュのサイズがでかい場合など)

データ一貫性が上がるかわりにパフォーマンスや耐障害性が下がる。トレードオフ

表15−1参照

ニアキャッシュの考慮

レプリケーションキャッシュと分散キャッシュのハイブリットモデル

パフォーマンスと応答性の不整合を生むため、スペースベースアーキテクチャには使用しない。

実装例

スペースベースアーキテクチャは、ユーザーからのリクエストが増加するアプリケーションや同時使用ユーザー数が10000人を超えるようなスループットのアプリケーションに適している。

この例はパフォーマンス、高スケーラビリティ、高レベルの弾力性が求められる。

コンサートチケット販売システム

ある期間ではまったく使われなかった中で、ユーザー数が爆発的に増加する瞬間がある

座席の空き情報をDBにリクエストしていたら、リアルタイム性を損なう

スペースベースアーキテクチャなら、デプロイメントマネージャーがユーザー数の増加を検知し、大量のリクエストを捌くために必要となる大量の処理ユニットを起動してくれる。

評価

図15−15

最高

弾力性、スケーラビリティ、パフォーマンス

トレードオフ

コスト、シンプルさ、テスト容易性

応用

code:sample.kt

質疑応答

参考